1. Technical Field of the Invention
The present invention generally relates to computer hardware and operating system software. More particularly, and not by way of any limitation, the present invention is directed to a system and method of limiting access by software code to protected computer hardware addresses and a predefined set of processor instructions.
2. Description of Related Art
The current method of making an operating system (OS) portable to multiple hardware platforms is to specify a set of hardware in a reference platform specification that the OS can access. The reference platform is a set of restricted hardware and hardware-vendor-supplied software modules that meet an industry standard for the minimum hardware/software required to execute an OS. The hardware vendor supplies the software modules with a standard interface to allow any OS to use them. For example, a software module known as the Processor Abstraction Layer (PAL) is responsible for initializing the processor hardware. When utilized properly, no other code is allowed to modify the processor registers that control the initialization of the processor. End users are not supposed to have access to this initialization code or to the hardware registers themselves. Other software modules such as the Hardware Abstraction Layer (HAL) and the System Abstraction Layer (SAL) are designed to provide OS isolation from other hardware in the platform.
In addition to enabling the OS provider to design an OS that operates on different platforms, the proper use of abstraction layers also enables the microprocessor manufacturer to make changes to the microprocessor while still providing compatibility with end-user software by providing the end user with new HAL code. For example, the manufacturer may change the procedures inside the processor for setting up the internal cache, clearing the TLBs, and so on without impacting the ability of end users to run their software on the platform.
The use of abstraction layers is beset with several deficiencies, however. First, developers such as OS developers may inadvertently implement pointers in their software that directly access hardware registers. Such “wild pointers” can cause problems when changes are made to the hardware, or when the OS is used on a different platform. If the OS includes machine-specific code, that code will not execute correctly if the hardware is modified or if the OS is run on a new hardware platform. There is currently no mechanism to identify inadvertent machine-specific code in an OS.
Secondly, in the PC environment, third party software vendors such as game manufacturers may intentionally implement software that directly accesses restricted hardware such as the VGA video card in order to enhance the performance of their games. Ideally, the game manufacturers should use service routines provided by the OS, and the OS should then access the video card. However, there is currently no mechanism to identify software that intentionally accesses restricted hardware.
Thirdly, a mechanism is needed to restrict access to the instruction core, from any source, to a predefined set of instructions related to the particular CPU type (e.g., the CPU's basic instruction set). In a CPU family, there may be follow-on CPUs that build upon a basic set of CPU instructions with extensions to the basic set. Problems can arise when sources authorized to access the basic set of instructions access the extended instruction set. It should be appreciated that a solution to the aforementioned deficiencies would be highly desirable.